1

De basisprincipes van avenue.quark

Velen willen het Web gebruiken om informatie te publiceren die ze in QuarkXPress Passport™-structuur hebben gemaakt. Uiteraard zijn er veel manieren om dat te doen. De meest efficiënte manier is echter om de content van dergelijke QuarkXPress Passport-documenten te scheiden van de documenten zelf en deze content op te slaan in een hiërarchieke structuur als XML. Vervolgens kunt u de content niet alleen opnieuw gebruiken op het Web, maar ook in andere structuren via de printer, een CD-ROM, noem maar op.

De avenue.quark™-software is speciaal ontworpen om op eenvoudige wijze uw QuarkXPress Passport-content uit het document op te halen en deze apart op te slaan in XML-structuur.

Met avenue.quark kunt u de content van QuarkXPress Passport-documenten scheiden en deze content opslaan in XML-structuur. Vervolgens kunt u op eenvoudige wijze de content op verschillende manieren opnieuw gebruiken, bijvoorbeeld op het Web. In dit hoofdstuk behandelen we in het kort de te volgen procedures en de begrippen die daarbij worden gehanteerd. In de daaropvolgende hoofdstukken wordt de materie nader onder de loep genomen.

Content is de informatie waaraan uw documenten hun waarde ontlenen. De content van een tijdschrift kan bijvoorbeeld zijn artikelen, foto's, interviews en grafieken.

Content kan ook worden gedefinieerd als wat het niet is. Kopregels, voetregels en vervolgregels als "Wordt vervolgd op pagina x" worden over het algemeen niet gezien als onderdeel van de content van een tijdschrift. Deze horen meer bij het uiterlijk ofte wel de verschijningsvorm van een tijdschrift aspecten van het tijdschrift die alleen nodig zijn om het tijdschrift meer impact te geven als het van de drukker komt. Het uiterlijk is afhankelijk van het medium dat wordt gebruikt om informatie openbaar te maken, terwijl content over het algemeen identiek blijft.

Met avenue.quark kunt u de content scheiden van het uiterlijk door die content uit uw QuarkXPress Passport-documenten te halen en deze op te slaan in XML-structuur. Vervolgens kunt u die content opnieuw gebruiken in verschillende verschijningsvormen in gedrukte vorm, op het Web, op CD-ROM enzovoort. U hoeft dan alleen maar het uiterlijk even aan te passen.

De afkorting XML betekent Extensible Markup Language (lett. Uitbreidbare Programmeertaal). XML moet u zien als een manier waarop u de structuur van content kunt specificeren en de verschillende stukjes van de contentpuzzel een zinnige naam kunt geven.

Content een naam geven

Waarom moeten we content een naam geven? Heel simpel: Hoewel we zelf een tijdschrift kunnen openslaan en meteen kunnen zien dat een specifieke tekstregel een kopregel is, kan een computer een dergelijk onderscheid niet zo makkelijk maken. Met XML kunt u informatie "coderen" op een manier die computers ook kunnen begrijpen. En als een computer eenmaal weet dat een specifieke tekstregel een kopregel is, kan hij deze regel ook vormgeven als een kopregel.

Om een stukje content in XML een naam te geven, voegt u in XML vóór de content een begincode en na de content een eindcode in, en wel als volgt:

Zoals u ziet, bestaat een begincode uit een elementnaam tussen een < en een >. Een eindcode ziet er identiek uit, met als verschil het /-teken na de <. In bovenstaand voorbeeld hebben we de tekst "Het Internet-verkeer is met 400% gegroeid" dus "geclassificeerd" als een kopregel door de tekst aan het begin en aan het eind een <kop>-code mee te geven.

De structuur aangeven

We weten dat een nieuwsbericht over het algemeen bestaat uit een kopregel, een subkop, platte tekst en hier en daar een foto of afbeeldingen met onderschriften. Computers weten dat soort dingen echter pas als u ze dat vertelt.

Met XML kunt u de structuur van uw documenten beschrijven aan de hand van DTD's, ofte wel documenttypedefinities. Een DTD geeft aan dat de informatie in een document gebruik zal maken van een specifieke set coderingen en dat een specifieke set structuurregels zal worden gevolgd. Een DTD voor een nieuwsbericht kan bijvoorbeeld het volgende aangeven:

• Elk artikel mag niet meer dan één <kop> hebben.
• Elk artikel kan wel of geen <auteursvermelding`> hebben.
• Elk artikel moet ten minste één <alinea> hebben.
• Elk artikel mag nul of meer <illustratie>-elementen bevatten.
• Iedere illustratie moet onmiddellijk worden gevolgd door niet meer dan één <onderschrift>.

Door zich aan de regels van een DTD te houden, kan een bedrijf er zeker van zijn dat de structuur van zijn documenten altijd vastligt en consequent wordt doorgevoerd. Hierdoor is het voor bedrijven veel eenvoudiger om content van het ene naar het andere medium te verplaatsen bijvoorbeeld van de drukpers naar het Web, of vice versa.

Avenue.quark werkt uitsluitend met DTD's. Kijk voor meer informatie over het maken en aanpassen van DTD's onder "Wat zijn DTD's?" en "Werken met DTD's" verderop in dit hoofdstuk.

Een "neutrale" structuur

XML is in zoverre een "neutrale" structuur dat het geen informatie bevat over de vormgeving. Daarom kan het worden gebruikt met een groot assortiment programma's, waarmee diverse typen vormgeving kunnen worden toegepast wanneer de content via diverse media wordt aangeboden.

Kijk voor een uitgebreidere bespreking van XML onder "Wat is XML?" verderop in dit hoofdstuk.

Heeft u eenmaal de content uit een QuarkXPress Passport-document opgehaald, dan kunt u die op verschillende manieren gebruiken. U kunt bijvoorbeeld XML-gecodeerde content dynamisch vertalen naar de HTML-structuur en het resultaat op het Web zetten. Deze methode van het converteren van QuarkXPress Passport-content naar HTML werkt vele malen beter dan het simpelweg exporteren van HTML, omdat u op deze manier de content beter kunt vormgeven, opnieuw vormgeven en reorganiseren.

Nu u een globaal idee heeft van wat avenue.quark is en hoe het werkt, gaan we eens wat dieper in de materie duiken, met name hoe XML in elkaar zit.

XML (Extensible Markup Language) is een manier om de structuur van documenten te specificeren en bepaalde stukken content met behulp van codes te labelen. De structurele regelaars van XML zorgen ervoor dat alle noodzakelijke onderdelen van dat document in de juiste volgorde aanwezig zijn. Door het labelen van content is het voor andere programma's gemakkelijker om die content te gebruiken of op het scherm weer te geven.

Voordat we gaan bekijken hoe XML dit allemaal doet, gaan we eerst even praten over het hoe en waarom.

XML is afgeleid van een oudere en veel ingewikkeldere programmeertaal met de naam SGML (Standard Generalized Markup Language). XML is gemaakt om veel problemen op te lossen die allemaal iets gemeen hadden, waarvan sommige oorspronkelijk zijn opgelost door SGML, terwijl andere weer uniek zijn.

Informatie structureren en labelen

XML wordt soms ook wel een "metataal" genoemd, omdat u aan uw wensen aangepaste en specifieke programmeertalen kunt definiëren. Dit doet u door een DTD (documenttypedefinitie) te maken. Een DTD geeft aan welke soort informatie een document mag bevatten, hoe de verschillende onderdelen van een document moeten worden gecodeerd (gelabeld), de volgorde waarin de onderdelen moeten staan en hoe vaak bepaalde onderdelen mogen voorkomen. Een document "voldoet" alleen aan een bepaalde DTD als daarbij de DTD-regels zijn nageleefd.

Met DTD's kunt u de structuur van documenten naar uw hand zetten. Als u de DTD van een document heeft, weet u meteen welke soort informatie u kunt verwachten wanneer u het document opent. DTD's stroomlijnen ook de verwerking van de informatie in XML-documenten op de computer. Als een computer een DTD kan "begrijpen", kan hij ook alle informatie in een XML-document die bij die DTD hoort" begrijpen". Uitgaande van een DTD van een document kunt u met een computerprogramma bijvoorbeeld zoeken naar een steeds terugkerend gegeven (bijvoorbeeld een bedrijfsnaam) in dat document, of een HTML-pagina produceren met een overzicht van hoeveel keer dat bepaalde gegeven in het document voorkomt (en dat kan dan een overzicht met bedrijfsnamen zijn).

Er zijn al gespecialiseerde DTD's ontwikkeld voor scheikunde, wiskunde, technische documentatie en zelfs enige romans. Mogelijke toepassingen richten zich op productie, softwarespecificatie en op de inspanningen op vrijwel elk terrein dat zich bezighoudt met de uitwisseling van gestructureerde informatie.

Tussen haakjes: In tegenstelling tot SGML kunt u met XML "goed gestructureerde" documenten maken dat wil zeggen documenten die zich houden aan de regels van XML maar niet zijn gebonden aan een specifieke DTD. Het is echter moeilijk om tussen documenten onderling een zekere consistentie aan te houden als er geen standaardnormen zijn. Dat is dan ook de reden waarom avenue.quark van u vraagt te werken met DTD's.

De zin van HTML

HTML heeft zich gemanifesteerd als een krachtige en flexibele structuur voor het weergeven van informatie op het World Wide Web. Het heeft echter twee beperkingen: het beschrijft alleen de vormgeving van gegevens zonder hun betekenis, terwijl u ook geen nieuwe HTML-codes kunt maken.

XML lost beide problemen in één keer op. Als u met XML gegevens in een XML-document van een code voorziet, kunt u de HTML-vormgeving baseren op deze codes. Stel dat u een XML-document heeft met een overzicht van bedrijven met nog wat nadere gegevens over deze bedrijven. Om dit overzicht om te zetten in een HTML Web-pagina waarin iedere bedrijfsnaam vet is, kunt u gewoon gebruik maken van een XML-naar-HTML-conversieprogramma en dit programma de opdracht geven om iedere regel met de code <bedrijfsNaam> vet te zetten. Dit houdt in dat u niet langer iedere bedrijfsnaam en elk bedrijfsadres handmatig hoeft vorm te geven. De daaruit voortvloeiende tijdsbesparing kan voor de makers van Web sites aanzienlijk zijn.

Gegevensuitwisseling

Aangezien computerprogrammatuur wordt ontwikkeld door verschillende personen en organisaties voor veel verschillende doeleinden, wordt informatie in verschillende structuren opgeslagen. Voorbeeld: Twee verschillende bedrijven slaan hun klantgegevens op in twee volkomen van elkaar afwijkende structuren, ondanks het feit dat de klantgegevens die de bedrijven opslaan (naam, adres, telefoonnummer enz.) zo goed als identiek zijn.

XML lost dit soort problematiek op met zijn gestandaardiseerde, fabrieksonafhankelijke structuur voor de overdracht van informatie tussen programma's onderling. XML is ontwikkeld, vervolmaakt en goedgekeurd door een groep professionele gebruikers uit verschillende bedrijfstakken die gezamenlijk het World Wide Web Consortium (de W3C) vormen. Iedereen die er gebruik van wil maken, kan vrij beschikken over de specificatie (zie www.w3.org), en veel bedrijven en bedrijfstakken doen dat al. (N.B.: Hoewel er nog geen Nederlandse versie van XML beschikbaar is, zijn de benamingen in deze handleiding toch al zoveel mogelijk vertaald. - vert.)

Als twee bedrijven met elkaar overeenkomen gebruik te maken van software die hun records kan converteren naar XML en waarbij wordt uitgegaan van een DTD waarmee beide partijeen het eens zijn, kunnen ze deze records willekeurig uitwisselen. Gegevensverlies door onverenigbare structuren is dan absoluut te verwaarlozen. Kijk voor meer informatie over DTD's en gegevensuitwisseling onder "Gestandaardiseerde DTD's" verderop in dit hoofdstuk.

Voor een uitgebreide bespreking van XML moet u kijken onder "Werken met XML" in dit hoofdstuk.

Een XML-document bevat gestructureerde gegevens die zijn opgedeeld in "elementen", die alle worden gedefinieerd door XML-codes.

Een XML-element bevat een juweeltje aan informatie, zoals een bedrijfsnaam, een kopregel of een artikelnummer. U kunt een element creëren door een stukje informatie tussen twee XML-codes te zetten: een begincode met de naam van het element tussen een kleiner dan-teken en een groter dan-teken, gevolgd door een eindcode die vrijwel identiek is, maar waarin vóór de elementnaam nog een schuine streep (/) staat. Een gecodeerd "naam"-element kan er als volgt uitzien:

Het is belangrijk dat u het verschil weet tussen een XML-element en een XML-code. Een XML-code is gewoon het label dat aan een stuk informatie is "gehangen"; in een XML-element zitten zowel dat stukje informatie als de codes die er omheen staan.

Met XML-codes kunt u de gegevens die daartussen staan beschrijven en een structuur geven. De volgende inleidende alinea bijvoorbeeld is gecodeerd met een <inleiding>-code:

Binnen het <inleiding>-element kunt u andere subelementen ook nog eens coderen om uw document meer structuur te geven:

<inleiding>

Syntax is belangrijk in XML-codes. In tegenstelling tot HTML-codes moet hier rekening worden gehouden met hoofd- en kleine letters; een <Naam>-code is iets anders dan een <naam>-code, die op zijn beurt weer verschilt van een <NAAM>-code. Iedere XML-code moet beginnen met een letter of een onderstreepteken (_); de lettertekens die daarna komen, kunnen gewoon letters zijn, onderstreeptekens, getallen, afbreektekens en punten, maar geen spaties of tabstops. De XML-codenaam <_.dir> is een correcte codenaam, maar de namen <_ dir> en <.dir> zijn dat niet. De <_ dir>-codenaam is niet correct, omdat er na het onderstreepteken een witruimte staat (wat een spatie of een tabstop kan zijn). De codenaam <.dir> is niet juist omdat deze begint met een punt in plaats van een onderstreepteken of een letter.

Het is ook handig om het verschil te weten tussen "elementen" en "elementtypen". Een elementtype kunt u zien als een specifieke codenaam die aan gegevens kan worden toegekend; een element is een stukje gegeven inclusief de codes die eromheen staan. Een document met bijvoorbeeld een lijst met namen en adressen heeft in feite maar twee elementtypen, namelijk <naam> en <adres>, maar honderden elementen die van deze codes gebruik maken.

Stel dat u werkt met elementen die zijn gecodeerd als <auto> en u wilt van elk <auto>-element dat u maakt extra informatie kunnen specificeren. U wilt bijvoorbeeld niet alleen maar een specifiek <auto>-element als auto omschrijven maar ook aangeven dat het een snelle, rode en dure auto is.

Er zijn verscheidene manieren waarop u dit kunt doen. Eén manier is om extra elementtypes te maken, zoals hieronder wordt aangegeven:

Een andere (en misschien "schonere") manier is gebruik te maken van een XML-functie die we attributen noemen. Attributen zijn bedoeld om informatie over een element te geven. Ze komen te staan binnen een begincode van een element, zodat er nooit twijfel bestaat over het element waarbij ze horen.

Een attribuut bestaat uit een attribuutnaam, gevolgd door een is gelijk-teken, gevolgd door een attribuutwaarde tussen aanhalingstekens. Het volgende element gebruikt bijvoorbeeld drie attributen om dezelfde informatie te geven als in het bovenstaande voorbeeld:

Attributen zijn om verscheidene redenen handig in het gebruik. Ze vergemakkelijken bijvoorbeeld het zoeken naar informatie in een document, terwijl ze in dit geval een overzicht genereren van alle <auto>-elementen met in de prijsspecificatie de waarde "duur". Ze kunnen ook handig zijn in combinatie met lege elementen; zie de volgende alinea voor meer bijzonderheden.

Lege elementen hebben wel een begin- en eindcode, maar er staan geen gegevens tussen, bijvoorbeeld:

Aangezien er tussen hun codes geen content staat, worden de begin- en eindcode van lege elementen vaak gecombineerd, zoals hier:

U kunt attributen gebruiken in combinatie met lege elementen om te verwijzen naar URL's of naar op externe media opgeslagen bestanden. Het volgende lege element kan bijvoorbeeld worden gebruikt (met de juiste XML-vertaler) om een plaatje van een auto weer te geven:

Bedenk wel dat het gewoon toevoegen van het attribuut "URL" aan een element geen garantie geeft dat de URL wordt geadresseerd wanneer het XML-bestand wordt verwerkt. Het programma dat het bestand verwerkt, moet wel weten wat het moet doen met het URL-attribuut.

Net als in HTML kunt u in een XML-bestand commentaar invoegen. Commentaar komt te staan tussen <!-- en -->, en wordt over het algemeen genegeerd door XML-processors. Als u bijvoorbeeld over de status van een <adres>-element commentaar wilt invoegen, zou u dat als volgt kunnen doen:

In HTML wordt commentaar over het algemeen gebruikt voor speciale opdrachten voor browsers en andere HTML-processors. In een poging XML-commentaar te beperken tot wat het is commentaar dus hebben de auteurs van de XML-specificatie een methode bedacht voor het invoegen van zelfgemaakte opdrachten in XML-bestanden en DTD's. Dergelijke opdrachten, die we verwerkingsinstructies noemen (ofte wel "VI's") staan gewoon tussen een <? en een ?>. Ze beginnen met de naam van het programma, gevolgd door een spatie en alle informatie die interessant kan zijn voor het desbetreffende programma. Verwerkingsinstructies kunnen overal worden gebruikt waar commentaar voorkomt.

Elk XML-document moet beginnen met wat we noemen een XML-declaratie. Net als bij een verwerkingsinstructie moet een XML-declaratie ook tussen een <? en een ?> staan. Hier is een voorbeeld van een XML-declaratie:

Het attribuut "versie" geeft aan dat dit document is gemaakt volgens de regels van XML 1.0. Het attribuut "standalone" vertelt ons dat alle programmadeclaraties die nodig zijn om dit XML-document te verwerken ook daadwerkelijk in het document staan.

Een entiteitsreferentie is een soort steno voor een letterteken, string of bestand. Door bijvoorbeeld in de content van een XML-document gebruik te maken van de entiteitsreferentie &lt; voor het kleiner dan-teken (<) zorgt u ervoor dat de XML-parser niet in de war raakt (die anders het "<"-teken abusievelijk zou aanzien voor het begin van een code). Kijk voor meer informatie over entiteitsreferenties onder "Entiteitsreferenties" bij "Werken met DTD's" verderop in dit hoofdstuk.

Om ervoor te zorgen dat een XML-document goed is gestructureerd, moet het beginnen met een XML-declaratie en een rootelement hebben waarin alle andere elementen staan (<artikel> in onderstaand voorbeeld). In een goed gestructureerd XML-document moet elk element in het document ook een overeenkomstige eindcode hebben. Hieronder ziet u een voorbeeld van een goed gestructureerd XML-document:

Een goed gestructureerd XML-document kan toch beperkt zijn in zijn toepassingsmogelijkheiden, tenzij het ook geldig is. Een XML-document wordt beschouwd als geldig wanneer het zich houdt aan de specificaties van een bepaalde DTD. Kijk voor meer informatie over DTD's en de validatie van XML-documenten onder "Wat zijn DTD's?" in dit hoofdstuk.

Een XML processor is in feite gewoon een programma dat een XML-bestand inleest en vervolgens daarmee iets doet. Er zijn verschillende soorten XML processors. Een XML processor kan een XML-bestand converteren naar een HTML Web-pagina, een PDF-bestand of een PostScript-bestand. Hij kan de content van een XML-bestand voor u voorlezen, of de content omzetten in braille. Een XML processor kan zelfs worden gebruikt voor het kopiëren van gestructureerde XML content naar een database.

XML-parsers

Een XML-parser (parsing = zinsontleding - vert.) herkent de regels van XML en controleert of een XML-document wel goed is gestructureerd. Een XML-parser controleert echter niet per se de validiteit ofte wel geldigheid van een XML-document ten opzichte van zijn DTD. Daarvoor heeft u een zogenaamde XML-validatieparser nodig (zie hieronder).

XML-validatieparsers

XML-validatieparsers vergelijken een XML-document met een DTD en controleren of het document overeenkomt met de conventies van die DTD. Een goede validatieparser geeft ook een constructieve terugkoppeling met betrekking tot eventuele problemen in het XML-bestand. Kijk voor meer informatie over XML-parsers onder "Wat zijn DTD's?" verderop in dit hoofdstuk.

Raadpleeg voor een snelle blik op XML-functies en regels Bijlage A "Snel wegwijs in XML" in hoofdstuk 7 "Bijlagen".

Een DTD (documenttypedefinitie) specificeert welke elementen er in een XML-bestand mogen staan en hoe deze elementen moeten worden gestructureerd. XML-documenten hoeven niet per se een overeenkomstige DTD te hebben. Zo lang een XML-bestand de regels aanhoudt van de standaard XML-syntax wordt het beschouwd als "goed gestructureerd" en kan het worden gelezen door elk programma dat XML ondersteunt of daarop is voorbereid. Maar alleen als een XML-bestand zich volledig houdt aan een specifieke DTD kunnen we het "geldig" noemen.

DTD's zijn belangrijk, omdat ze voor een betrouwbare, goed gedocumenteerde structuur voor XML-documenten zorgen. Zonder DTD's zouden twee samenwerkende bedrijven kunnen beslissen hun XML-documenten op volkomen verschillende manieren te structureren en te coderen, met als gevolg dat de opgeslagen gegevens niet compatibel zijn, zelfs nadat beide bedrijven zijn overgestapt op XML. Als ze echter uitgaan van dezelfde DTD misschien van een DTD die ze gezamenlijk hebben ontwikkeld, of een DTD die tot standaard in hun bedrijfstak is verheven kunnen ze op een eenvoudige en betrouwbare manier gegevens uitwisselen.

Er zijn twee soorten DTD's: Externe DTD's en interne DTD's.

Technisch gesproken bestaat een DTD uit een lijst met programmeerdeclaraties (elementdeclaraties, specificatiedeclaraties, entiteiten, notaties, verwerkingsinstructies en commentaar), die allemaal zijn samengevat in een DOCTYPE-declaratie. Waar in deze handleiding wordt gesproken over "externe DTD's" en "interne DTD's" zijn technisch gezien geen volledige DTD's. Voor het gemak en ook al omdat het over het algemeen vrij gebruikelijk is, zullen we deze terminologie hier toch hanteren.

Externe DTD's

Een externe DTD (ofte wel externe subset) is een bestand met een lijst van programmeerdeclaraties. Externe DTD's kunnen op eenvoudige wijze tussen meerdere XML-documenten en organisaties gezamenlijk worden gebruikt. Om in een XML-document een externe DTD te gebruiken, zet u gewoon aan het begin van het XML-bestand de desbetreffende verwijzing, zoals:

Interne DTD's

Een interne DTD (ofte wel interne subset) is in feite geïntegreerd in het XML-bestand dat hij beschrijft. Om in een XML-bestand een interne DTD te kunnen gebruiken, zet u deze gewoon aan het begin van het XML-bestand, en wel zo:

Indien in een document gebruik wordt gemaakt van een externe DTD (of een andere externe entiteit) moet het attribuut "standalone" in de eerste regel op "nee" worden gezet. Kijk voor meer informatie onder "Entiteitsreferenties gebruiken" verderop in dit hoofdstuk.

Interne en externe DTD's combineren

In een XML-document kunt u een externe DTD specificeren en vervolgens aan deze DTD een interne DTD toevoegen of de externe DTD overschrijven door een interne DTD. Een dergelijk XML-document kan er als volgt uitzien:

Een DTD maken is niet een kwestie van even gaan zitten en er één schrijven. Aan dit proces gaat namelijk een behoorlijke planning vooraf, zeker als u het meteen goed wilt doen.

Voordat u van plan bent uw eigen DTD te maken, kunt u misschien beter eens beginnen met een gestandaardiseerde DTD. Kijk voor meer informatie over deze mogelijkheid onder "Gestandaardiseerde DTD's" verderop in dit hoofdstuk.

Een goede manier om te beginnen, is te bedenken wat u precies wilt dat uw DTD voor u doet. Probeer eerst eens aan te geven welke elementen u wilt gebruiken. Als u gebruik wilt maken van elementen als <adres>, bedenk dan of u deze elementen nog wilt onderverdelen in subelementen als <straatAdres>, <huisnummer>, <woonplaats>, <provincie>, en <ZIPcode>. (Denk daar met name goed over na als er een grote kans bestaat dat u de inhoud van uw XML-bestanden in een database gaat zetten.)

Dit was het eenvoudige gedeelte. Vervolgens moet u gaan brainstormen over de relatie tussen al deze elementen. Een DTD kan specificeren welke elementen zijn toegestaan, in welke volgorde ze moeten staan en welke (en hoeveel) subelementen ze mogen bevatten. Bovendien kan worden aangegeven welke andere elementen een bepaald element mag bevatten, en of in een specifiek element wel of niet gegevens moeten staan.

Eliotte Rusty Harold raadt ons in XML: Extensible Markup Language aan gebruik te maken van een tabel om u te helpen de relatie vast te stellen tussen de verschillende elementen in uw DTD. Deze tabel moet dan de volgende kolomindeling hebben (de gegevens in onderstaande kolommen dienen alleen als voorbeeld):

Iedere rij in de tabel moet een element zijn dat u wilt gebruiken in uw DTD.

Net als een XML-bestand bestaat een DTD uit platte tekst. Voor een XML-bestand gelden vier mogelijkheden, nl. geen DTD, een externe DTD, een interne DTD of zowel een externe als interne DTD.

Ongeacht welk type DTD een XML-document gebruikt, zal er in de proloog (het openingsgedeelte) naar moeten worden verwezen, na de XML-declaratie en vóór de "body" van het XML-document. De DTD-sectie begint met "<!DOCTYPE rootnaam [" en eindigt met "]>". Hieronder ziet u een voorbeeld van een volledig XML-document met een complete DTD (vet gedrukt):

Laten we dit eens analyseren:

• De rootnaam (het woord na <!DOCTYPE) specificeert het rootelementtype van het XML-bestand.
• De vierkante openings- en sluithaken geven de interne DTD aan.
• "<!ELEMENT boodschap ANY>" definieert een elementtype met de naam "boodschap". "!ELEMENT" betekent "Wat hierna volgt is een elementtypedeclaratie." Vervolgens komt de naam van het element ("boodschap") en wat informatie over datgene wat dit element kan bevatten (in dit geval "ANY", wat zowel tekst- als extra elementen kan betekenen).

Zoals u kunt zien, specificeert iedere elementtypedefinitie zowel de naam van het element als het soort gegevens dat dit element kan bevatten. Als u de elementtypedefinitie voor <boodschap> zodanig wilt veranderen dat er alleen maar tekst kan instaan (dat wil zeggen geen andere elementen), dan kan dat door het sleutelwoord "WILLEKEURIG" te wijzigen in "(#PCDATA)", zoals we dat hieronder hebben gedaan:

Maar misschien kunt u dat beter niet doen, omdat deze wijziging inhoudt dat het rootelement van uw document alleen geparsde tekeninformatie kan bevatten (zie onderstaande kanttekening). U kunt dan geen elementen meer toevoegen als u de informatie nog eens zou willen onderverdelen.

"PCDATA" betekent "parsed character data": dat wil zeggen dat tekst zowel entiteitsreferenties, commentaar als verwerkingsinstructies kan bevatten.

Laten we eens kijken naar een reëlere DTD. De volgende interne DTD definieert een structuur voor een filialenoverzicht:

U ziet wel dat we commentaar hebben tussengevoegd om aan te geven dat <filialenOverzicht> het rootelement van de DTD is. Dit hebben we gedaan, omdat een DTD niet expliciet een rootelement kan aanwijzen; het specificeren van een rootelement is technisch gesproken de taak van de regel !DOCTYPE in een XML-document. Maar het is wel een goed idee rootelementen te specificeren aan de hand van commentaar, zodat de gebruikers van de DTD kunnen zien wat ze inhouden.

Sommige DTD's hebben meer dan één element dat dienst kan doen als rootelement. U kunt bijvoorbeeld een DTD schrijven met definities voor zowel een witboek als een document waarin veelvoorkomende vragen worden beantgwoord, en vervolgens die DTD gebruiken om beide documenttypen te maken door gewoon <whitePaper> of <techDoc> te specificeren als het rootelement van elk XML-bestand.

De resterende regels in de DTD zijn elementdeclaraties voor adres, vestigingsplaats, provincie, postcode, land, telefoonnummer, faxnummer en e-mailadres van elk kantoor afzonderlijk.

Bovenstaande DTD werkt misschien goed in uw situatie, maar echt voordeel van de XML-functies heeft u niet. Er wordt bijvoorbeeld helemaal niet aangegeven welke adreselementen bij welk kantoor horen, terwijl een bepaalde volgorde voor de gegevens ook ver is te zoeken. U zou dus een document kunnen maken met alle verschillende steden, adressen, telefoonnummers enzovoort in een willekeurige volgorde dat qua geldigheid nog steeds zou voldoen aan deze DTD.

Om de DTD een overzichtelijke structuur te geven, heeft u een manier nodig om alle elementen voor iedere lijst afzonderlijk aan elkaar te knopen en ze in een specifieke volgorde te zetten. Eén manier om dit te doen is via een container element waarin alle relevante informatie voor één kantoor (dat we <filiaal> noemen) terechtkomt, waarna we specificeren welke subelementen in dat container element moeten komen en in welke volgorde dat moet gebeuren. We kunnen dit allemaal doen door aan de DTD één regel (vetgedrukt) toe te voegen:

Wat dit nieuwe element ons vertelt, is het volgende: "Als het document een element bevat met de naam <filiaal>, moet dat element precies een van elk van de volgende elementen bevatten, in deze volgorde en niets anders."

Maar wat nu als sommige van uw filialen een adres hebben dat bestaat uit meer dan één regel? U kunt in een lijst met subelementen meerdere elementen opnemen door aan het eind van de elementnaam een +-teken te zetten. Als u in ons <filiaal>-element één of meer <straatAdres>-elementen wilt hebben, zouden we het volgende kunnen doen:

En wat als sommige van uw filialen geen fax hebben? Of als ze meer dan één fax hebben? Wel, om aan te geven dat een element niet of juist meerdere malen voorkomt, moet u aan het eind van een elementnaam een *-teken "plakken", zoals hier:

Stel dat sommige van uw filialen zijn gevestigd in een land waar een postcode totaal onbekend is? Om aan te geven dat een element niet of slechts éénmaal voorkomt, moet u aan het eind van de elementnaam een vraagteken zetten, bijvoorbeeld:

Wat in de Verenigde Staten een "staat" heet, kan ergens anders wel een andere naam hebben. Canada bijvoorbeeld is verdeeld in provincies. Als u filialen heeft in zowel de Verenigde Staten als in Canada, heeft u de mogelijkheid een <staat>- element of een <provincie>-element op te nemen. Dit kunt u doen door beide opties tussen haakjes te zetten, gescheiden door een |-teken, zoals u hier kunt zien:

Ten slotte kunnen we garanderen dat een <filialenOverzicht> alleen maar bestaat uit <filiaal>-vermeldingen door de definitie van <filialenOverzicht> te wijzigen van WILLEKEURIG in (filiaal*). Met als eindresultaat:

Even een korte samenvatting:

De speciale symbolen kunnen worden gebruikt in combinatie met de haakjes om complexe elementtypedeclaraties te maken, zoals in onderstaande DTD, die is ontworpen om een overzicht te geven met communicatieve informatie op een dag-tot-dag basis:

Het onderwerp van deze lijst kan dagelijks op kantoor, thuis of onderweg zijn op een zakenreis. Dus kan in elk <communInfo> element een van de volgende lijsten met informatie worden opgenomen, met de subelementen in de opgegeven volgorde:

• De datum, een zakelijk telefoonnummer, nul of meer zakelijke faxnummers, het e-mailadres en nul boodschappen of één boodschap.
• De datum, één of meer privételefoonnummers en/of nummers van piepers, nul of meer privéfaxnummers, het e-mailadres en nul boodschappen of één boodschap.
• De datum, één of meer mobiele telefoonnummers en/of nummers van piepers, één of meer mobiele telefoonnummers, het e-mailadres en nul boodschappen of één boodschap.

U kunt uw XML-documenten zodanig schrijven dat ze heel eenvoudig in de HTML-structuur kunnen worden vertaald. Als u dat doet, kunt u in uw XML-bestand codes opnemen als <BR> en <HR>, met de bedoeling deze woordelijk in het HTML-bestand te vertalen.

U kunt dit niet echt doen in XML, omdat elk element een sluitcode moet hebben. U kunt echter wel zogenaamde EMPTY-codes maken en het aan een XML-naar-HTML-conversieprogramma overlaten deze om te zetten in goede uitvoercodes. Om bijvoorbeeld <HR>-codes mogelijk te maken, kunt u in de DTD de volgende regel opnemen:

Om deze code te kunnen gebruiken, kunt u in uw XML-bestand bijvoorbeeld de volgende regel invoegen:

U kunt dit niet opnemen als "<HR>", omdat iedere XML-code een eindcode moet hebben of moet eindigen met een schuine deelstreep, maar dat is geen probleem; een XML-naar-HTML-conversieprogramma zal de <HR/> omzetten in een <HR>.

EMPTY-codes worden vaak gebruikt voor afbeeldingen. De URL van de afbeeldingsgegevens is dan opgeslagen in een van de attributen van de EMPTY-code. Kijk voor meer informatie over attributen onder "Attributen definiëren" verderop in dit hoofdstuk.

Een tekenverwijzing is een manier om Unicode-tekens weer te geven in geparsde tekstgegevens. De syntax voor tekenverwijzingen is als volgt:

Om bijvoorbeeld vóór het getal 500 in een <getal>-element het euroteken te zetten, zou u het volgende kunnen doen (de tekenverwijzing is vetgedrukt):

Het is de taak van de XML processor om bij de uitvoer de correcte Unicode-tekens te vervangen door tekenverwijzingen.

Een entiteitsreferentie kunt u zien een stukje tekst dat iets anders weergeeft, zoals een letterteken, een tekststring, een extern opgeslagen XML-bestand of een binair bestand. Er zijn vijf soorten entiteitsreferenties:

• Geparsde interne entiteitsreferenties, voor het weergeven van vaak voorkomende tekststrings
• Geparsde externe entiteitsreferenties, om te verwijzen naar extern opgeslagen tekstbestanden die te analyseren gegevens bevatten
• Niet geparsde externe entiteitsreferenties, vaak gebruikt voor verwijzingen naar binaire bestanden als illustratie-, spreadsheet- en geluidsbestanden
• Interne parameterentiteitsreferenties, voor het weergeven van vaak gebruikte programmeerdeclaraties in DTD's (altijd geparsd)
• Externe parameterentiteitsreferenties, voor verwijzingen naar extern opgeslagen tekstbestanden in DTD's die te analyseren gegevens bevatten (altijd geparsd)

Deze soorten entiteitsreferenties worden hieronder gedetailleerd uit de doeken gedaan.

Wat is het verschil tussen een entiteit en een entiteitsreferentie? Een entiteitsreferentie is een soort steno die u in een XML-document invoegt en die een entiteit voorstelt. Een entiteit is de content die de entiteitsreferentie vervangt wanneer het XML-bestand wordt verwerkt.

Geparsde interne entiteitsreferenties

Een geparsde interne entiteitsreferentie is eigenlijk een soort steno voor een tekststring die u van plan bent vaak in een bepaald XML-document te gebruiken. De syntax voor het declareren van een geparsde interne entiteitsreferentie in een DTD is als volgt:

Stel dat u een XML-document gaat opzetten dat een lijst bevat met personeelsleden met over elk personeelslid een klein beetje extra informatie. In elk personeelsrecord moet de zin "Aantal jaren in dienst bij het bedrijf:" staan, gevolgd door een getal. In plaats van deze zin steeds weer handmatig in te moeten tikken, kunt u hiervoor als onderdeel van de DTD van het document beter een geparsde interne entiteitsreferentie maken en wel als volgt:

Om in het XML-document gebruik te kunnen maken van "jaren" als geparsde interne entiteitsreferentie, kunnen we het volgende doen:

Wanneer dit <werknemer>-element wordt verwerkt, zal de XML processor de geparsde interne entiteitsreferentie "uitpakken", met als resultaat de volgende XML:

Er zijn in XML vijf reeds gedefinieerde geparsde interne entiteitsreferenties voorhanden. In tegenstelling tot alle andere geparsde interne entiteitsreferenties vormen deze onderdeel van de XML-specificatie en hoeven niet meer te worden gedeclareerd.

Stel dat u bijvoorbeeld in de content van uw XML-document gebruik wilt maken van het groter dan-teken (>). Zoals u weet, is het groter dan-teken de eindcode in XML. Om te voorkomen dat de XML processor hierdoor in verwarring raakt, kunt u overal waar dat nodig is het groter dan-teken vervangen door "&gt;". Om bijvoorbeeld in een XML-bestand de expressie "het geheel > de som van zijn samenstellende delen" te gebruiken, kunt u het volgende doen:

Er zijn drie beperkingen bij het gebruik van geparsde interne entiteitsreferenties:

• U moet een geparsde interne entiteitsreferentie (met uitzondering van de vijf hierboven vermelde) declareren voordat u deze gebruikt.
• U kunt een geparsde interne entiteitsreferentie gebruiken in elementcontent en in attribuutwaarden.
• U kunt een geparsde interne entiteitsreferentie gebruiken binnen een andere geparsde interne entiteitsreferentie, maar alleen als dat niet leidt tot een doorlopende verwijzing (lus). Het is bijvoorbeeld niet toegestaan om geparsde interne entiteitsreferentie A te gebruiken in geparsde interne entiteitsreferentie B als geparsde interne entiteitsreferentie B al wordt gebruikt in geparsde interne entiteitsreferentie A.

Geparsde externe entiteitsreferentie

In een geparsde externe entiteitsreferentie kunt u content opnemen die is opgeslagen in een extern tekstbestand. Geparsde externe entiteitsreferenties moeten op een van de volgende manieren in een DTD worden gedeclareerd:

In het eerste voorbeeld kunt u de URL van een specifiek bestand gebruiken. In het tweede voorbeeld kunt u de naam van een resource gebruiken, die op zijn beurt weer kan verwijzen naar een URL; de URL die volgt is een "backup" URL, die alleen mag worden gebruikt als de naam niet kan worden gevonden.

Geparsde externe entiteitsreferenties kunnen worden gebruikt voor het gezamenlijk gebruiken van content tussen XML-bestanden onderling. Onderstaand vindt u een compleet voorbeeld van een XML-document waarin de content is opgeslagen in een tekstbestand met de naam "mijnbestand.txt" op de Web site van Quark™:

Dit is handig omdat u de content in "mijnbestand.txt" ook kunt gebruiken in andere XML-bestanden.

Als een document gebruik maakt van externe entiteitsreferenties, moet u het "standalone"-attribuut in de XML-declaratie op "no" zetten.

Niet geparsde externe entiteitsreferenties

Wat gebeurt er als u in een XML-document wilt verwijzen naar een illustratie-, spreadsheet-, geluidsbestand, HTML-bestand of een ander niet-HTML-bestand? U kunt niet gebruik maken van een geparsde externe entiteitsreferentie, omdat de XML processor zal proberen uw binaire bestand te parsen, wat ongetwijfeld tot foutmeldingen zal leiden.

Om te probleem te vermijden, kunt u het eind van de externe entiteitsreferentie een notatie meegeven. Een notatie vertelt de XML processor gewoon om het doelbestand niet te parsen, en geeft meteen aan wat soort bestand het is. De syntax voor het declareren van een notatie in een DTD is als volgt:

Om bijvoorbeeld een relatie te leggen tussen JPEG-bestanden en Adobe® Photoshop®, kunt u aan de DTD de volgende notatie toevoegen:

Om een notatie te activeren in de declaratie van een externe entiteitsreferentie, moet u de volgende syntax aanhouden:

Om bijvoorbeeld een entiteit te maken met de naam "mijnIllustratie" die verwijst naar een URL met een JPEG-bestand, kunt u de volgende codering gebruiken:

U kunt ook gebruik maken van de PUBLIEK-syntax met notaties, waarbij eerst een publieke notatienaam en vervolgens een "backup"notatie URL wordt gespecificeerd:

Andere manieren om naar externe bestanden te verwijzen: Niet geparsde entiteitsreferenties zijn niet de enige manier om in XML-bestanden te verwijzen naar externe bestanden zonder op te geven dat ze moeten worden geparsd. U kunt de URL van een dergelijk bestand ook opslaan als een standaardelement of als specificatiecontent. Het eerste voorbeeld hieronder verwijst naar de URL van een illustratiebestand als elementcontent, terwijl het tweede voorbeeld verwijst naar dezelfde URL maar dan als attribuutcontent:

Of u niet geparsde entiteiten, elementen of attributen wilt gebruiken bij de verwijzing naar niet-XML-bestanden bepaalt u helemaal zelf. Elk van deze methoden werkt evengoed, zolang het programma dat het XML-bestand verwerkt maar weet dat de URL's ook URL's zijn.

Interne parameterentiteitsreferenties

Als u een entiteitsreferentie wilt maken die alleen wordt gebruikt in een specifieke DTD, moet u een parameterentiteitsreferentie maken. Een interne parameterentiteitsreferentie lijkt heel veel op een geparsde interne entiteitsreferentie, met dien verstande dat deze begint met een %-teken in plaats van een &-teken, zowel in de declaratie als bij het gebruik:

U kunt in de externe subset van een DTD interne parameterentiteitsreferenties op dezelfde manier gebruiken als geparsde interne entiteiten in een XML-document. Hieronder gebruiken we bijvoorbeeld een interne parameterentiteitsreferentie om op een korte manier te verwijzen naar een contentmodel dat een persoonsnaam beschrijft:

Dit is handig, omdat u nu gemakkelijk de definitie van alle soorten namen in één keer kunt wijzigen. Als u bijvoorbeeld ooit nog van plan bent ook de middelste namen voor alle werkgevers, werknemers en klanten op te slaan, hoeft u alleen maar bovenstaande interne parameterentiteitsdeclaratie als volgt te wijzigen:

Vergeet niet dat dit type interne parameterentiteitsreferentie alleen kan worden gebruikt in de externe subset van een DTD.

Externe parameterentiteitsreferenties

Een externe parameterentiteitsreferentie lijkt heel veel op een geparsde externe entiteitsreferentie, met dien verstande dat deze begint met een %-teken in plaats van een &-teken, zowel in de declaratie als tijdens het gebruik. De volgende twee regels (uit een interne subset van een XML-document) maakt bijvoorbeeld eerst een entiteitsreferentie die verwijst naar een externe DTD met de naam "standaardKopregel.dtd", waarna deze externe DTD vervolgens in het XML-bestand wordt opgenomen:

Kijk voor meer informatie over het praktijkgebruik bij "Publieke DTD's gebruiken" verderop in dit hoofdstuk.

Parameterentiteitsreferenties kunnen alleen in een DTD worden gebruikt.

Interne en externe parameterentiteitsreferenties kunnen samen worden gebruikt. U kunt bijvoorbeeld interne parameterentiteitsreferenties gebruiken in de interne subset om te verwijzen naar entiteiten die zijn gedefinieerd in de externe subset. Dit is handig, omdat u hierdoor de definitie van een entiteit kunt wijzigen zonder dat de interne subset van XML-bestanden die gebruik maken van de entiteit hoeft te worden gewijzigd. U kunt dus in een tekstbestand met de naam "entiteitsBestand.txt" bijvoorbeeld de volgende declaratie opnemen:

En vervolgens, in de interne subset van XML-documenten, het volgende opnemen:

Hierdoor kunt u de definitie van de entiteitsreferentie naamEntiteit in een willekeurig aantal XML-documenten wijzigen door deze gewoon te veranderen in het bestand "entiteitsBestand.txt".

Naast content kunnen elementen ook attributen hebben (zie "Wat is XML?" in dit hoofdstuk). Er bestaat nogal wat onenigheid over de rol die attributen spelen, maar in het bestek van deze handleiding gaan we ervan uit dat een attribuut informatie moet bevatten over een element die van belang is voor de XML processor, maar die geen onderdeel is van de content van het XML-bestand zelf.

Stel dat u XML gebruikt om een overzicht bij te houden van boeken die u op een Web site wilt publiceren. Deze lijst kan op twee manieren worden weergegeven: als een complete lijst, of als een lijst met alle boeken die in de laatste 10 dagen aan de lijst zijn toegevoegd. Om dit te laten werken, moet het XML-document de datum aangeven waarop iedere boektitel is ingevoerd.

U kunt natuurlijk aan de definitie van de <boek>-code een <datumInvoer>-subcode toevoegen, maar de datum waarop een bepaalde boektitel in uw systeem is ingevoerd, is in werkelijkheid geen stukje informatie over het boek zelf, dus u zou in dit geval kunnen kiezen voor het maken van een attribuut met als naam "datumInvoer".

De syntax voor attribuutdeclaraties is als volgt:

Geef in dit geval dus het <boek>-element een "datumInvoer"-attribuut met een standaardwaarde van "01/01/2000", waarna we aan de DTD de volgende regel toevoegen:

Om vervolgens met dit attribuut in een <boek>-element te kunnen werken, kunnen we gewoon een attribuutwaardepaar gebruiken, zoals hier:

Dit attribuut geeft de XML processor de informatie die nodig is om de boektitels te tonen gebaseerd op de datum waarop de titel werd ingevoerd.

Vereiste, impliciete en vaste attributen

Een attribuut kan vereist, impliciet of vast zijn. Een vereist-attribuutstandaardwaarde geeft aan dat het element dit attribuut moet bevatten. De volgende attribuutdeclaratie bijvoorbeeld geeft aan dat elk <boek>-element een "datumInvoer"-attribuut moet hebben:

Een impliciet-attribuutstandaardwaarde geeft aan dat het element wel of niet dit attribuut kan hebben, te bepalen door de XML-auteur. De volgende attribuutdeclaratie bijvoorbeeld geeft aan dat een <boek>-element wel of niet een "datumInvoer"- attribuut zal bevatten:

Een vast-attribuutwaarde geeft aan dat het attribuut voor elk element een exacte waarde moet bevatten. De volgende attribuutdeclaratie bijvoorbeeld laat ons weten dat elk <boek> een "datumInvoer"-waarde moet hebben die gelijk is aan"11/11/1998":

In dit voorbeeld gaat de XML processor ervanuit dat elk <boek>-element een "datumInvoer"-attribuut heeft dat is ingesteld op "11/11/1998," zelfs als het attribuut wordt weggelaten.

Als een attribuutdeclaratie een standaardwaarde heeft, maar niet specificeert #REQUIRED, #IMPLIED of #FIXED, gaat de XML processor uit van de standaardwaarde voor het attribuut iedere keer als het attribuut wordt weggelaten.

Attribuuttypen

Het CDATA-sleutelwoord in ons voorbeeld van een attribuutdeclaratie geeft aan dat we willen dat dit attribuut tekstgegevens zal bevatten. CDATA is echter slechts één van de mogelijke attribuuttypes. Hieronder volgt de complete lijst.

• Een CDATA-attribuut kan tekstgegevens en entiteitsreferenties bevatten.
• Een ENTITY-attribuut moet de naam bevatten van een niet-geparsde entiteit die in de DTD wordt gedeclareerd. (Kijk voor meer informatie over entiteiten onder "Entiteitsreferenties gebruiken" in dit hoofdstuk.) U kunt bijvoorbeeld een ENTITY-attribuut gebruiken met de URL van een afbeelding:

• Een ENTITIES-attribuut moet de namen bevatten van een of meer niet-geparsde entiteiten die in de DTD worden gedeclareerd. De lijst met entiteiten moet worden gescheiden door spaties. Bij voorbeeld:

• Een opsommingslijst-attribuut mag één naam bevatten uit een lijst met namen die tussen haakjes staat. ("Naam" betekent hier dat de waarden in de lijst bij de naamgeving dezelfde regels moeten volgen als bij XML-elementen.)
• Om een opsommingslijstattribuut te gebruiken, moet u in plaats van een sleutelwoord gewoon de lijst met namen toevoegen aan de attribuutdeclaratie. In de volgende regel wordt bijvoorbeeld aangegeven dat het "verkoopStatus"-attribuut van het <boek>-element alleen "In_Uitverkoop" of "Reguliere_Prijs" mag bevatten:

• Een ID-attribuut geeft aan dat elk element voor dat attribuut een unieke waarde (eventueel) moet hebben. Bijvoorbeeld:

Een ID-attribuut moet een gedeclareerde standaardwaarde hebben van #IMPLIED of #REQUIRED. Geen enkel element mag meer dan één attribuut hebben.

• Een IDREF-attribuut moet "verwijzen naar" een ander element in het XML-document dat een ID-attribuut heeft. Bijvoorbeeld:

• De waarde van een IDREFS-attribuut bestaat uit een reeks IDREF-attributen, gescheiden door spaties.
• Een NMTOKEN-attribuutwaarde kan verschillende tekens bevatten, zoals letters, getallen, onderstreeptekens, punten enzovoort, maar er mogen geen spaties instaan. Onderstaand voorbeeld is dus niet geldig, omdat in de zin "Mijn lokale naam" spaties staan:

• Een NMTOKENS-attribuut is gelijk aan een NMTOKEN-attribuut, met dien verstande dat de attribuutwaarde een lijst met NMTOKENS kan zijn, die door spaties worden gescheiden.

• Een NOTATION-attribuut moet één of meer XML-notatienamen uit de DTD bevatten. Hiermee kunt u notaties maken die programma's specificeren waarmee afbeeldingen en films kunnen worden bekeken c.q. afgespeeld en vervolgens een elementattribuut gebruiken om er zeker van te zijn dat voor een bepaald stukje content het juiste programma wordt gebruikt. Bijvoorbeeld:

• Deze informatie vertelt het programma dat de XML verwerkt dat het het programma PictureViewer kan gebruiken om het afbeeldingenbestand te openen en het programma MoviePlayer om het filmbestand te openen.

Een element mag nooit meer dan één NOTATION-attribuut hebben.

• Een opsom-NOTATION-attribuut moet een lijst van één of meer XML-notatienamen tussen haakjes uit de DTD bevatten. U kunt bijvoorbeeld notaties maken die meerdere programma's specificeren die afbeeldingen kunnen laten zien c.q. films kunnen afspelen, en vervolgens een elementattribuut gebruiken om ervoor te zorgen dat voor een bepaalde stukje content de goede serie programma's wordt gebruikt. Dit zou er dan als volgt kunnen uitzien:

In plaats van één element voor zowel afbeeldingen als films maken we hier twee afzonderlijke elementen, namelijk <afbeelding> en <film>. Voor elk van deze elementen geeft de DTD aan dat er twee verschillende programma's kunnen worden gebruikt om het bestand te bekijken. Welk programma uiteindelijk wordt gekozen, wordt aangegeven in iedere individuele <element>-code in de XML-tekst.

Het attribuut xml:lang

Met het attribuut "xml:lang" kunt u opgeven welke taal in een element wordt gebruikt. Dit attribuut moet een van de volgende elementen bevatten:

• Een tweeletterige taalcode gedefinieerd door ISO 639, optioneel gevolgd door een koppelteken en een subtype (dit is altijd een landencode)
• Een IANA-geregistreerd taalnummer, voorafgegaan door "i-" of "I-"
• Een door de gebruiker gedefinieerde taalcode, voorafgegaan door "x-" of "X-"

N.B.: Deze attributen niet zijn voorgedefinieerd u moet ze declareren voordat u ze gebruikt.

Om aan te geven welke taal u wilt, moet u gewoon de desbetreffende taalcode toekennen. In de volgende DTD wordt bijvoorbeeld een "xml:lang"-element opgegeven, terwijl het element in de XML-tekst als taal Engels specificeert met als normcode ISO 639:

U kunt taalsubtypes specificeren door aan de taalnaam een koppelteken en een extensie toe te voegen. In onderstaand element wordt bijvoorbeeld aangegeven dat als taal Internationaal Engels (zoals dat in Groot-Brittannië wordt gesproken) wordt gebruikt in plaats van Amerikaans Engels:

Het attribuut xml:space

Met het attribuut "xml:space" kunt u het programma dat de XML verwerkte laten weten dat het alle lege spaties voor een element en zijn "kinderen" zo moet laten staan (tenzij een van de "kinderen" van het element de code terugzet naar een andere waarde). In onderstaande DTD bijvoorbeeld wordt een "xml:space"-attribuut gespecificeerd, terwijl het element in de XML-tekst dat attribuut voor dat element en zijn kinderen instelt op "gehandhaafd":

U kunt de <![IGNORE[]]>-code gebruiken om de XML parser te vertellen een bepaald tekstgedeelte in een externe DTD te negeren. Wat dacht u hier van:

U kunt de XML parser vertellen de tekst tussen de codes te parsen door IGNORE gewoon te veranderen in INCLUDE, en wel als volgt:

Zoals we al hebben gezegd, kunt u verwijzen naar een externe DTD in de DOCTYPE-declaratie van een XML-document, zoals we hier laten zien:

Als u gebruik maakt van een DTD die is goedgekeurd door een organisatie als de International Standards Organization (ISO), kunt u een PUBLIC-entiteitsreferentie gebruiken die de naam specificeert van een algemeen beschikbare kopie van de DTD. Wanneer u dat doet, moet u daarin ook de URL van een SYSTEM DTD-bestand opnemen, zodat u ergens op kunt terugvallen als de PUBLIC-kopie van de DTD niet beschikbaar is.

In sommige gevallen is het best handig afzonderlijke DTD's te maken om verschillende delen van een document te definiëren. Uw bedrijf kan bijvoorbeeld één DTD gebruiken voor alle kop- en voetregelinformatie in zijn XML-bestanden, maar weer andere DTD's voor documentteksten die zijn geproduceerd door diverse afdelingen van het bedrijf. U kunt een dergelijke situatie opvangen door gewoon één hele nieuwe DTD te maken waarin de verscheidene DTD's zijn opgenomen die u nodig heeft en waarin de volgorde wordt aangegeven van hun rootelementen, bijvoorbeeld als volgt:

Voor documenten die worden gemaakt met deze DTD is <QARapportDoc> het rootelement, terwijl <standaardKopregel>, <QARapport> en <standaardVoetregel> de rechtstreekse subelementen zijn. Een document dat gebruik maakt van deze DTD kan er als volgt uitzien:

In sommige productiesituaties worden DTD's gebruikt die per gebruiksmogelijkheid vrijwel identiek zijn, maar waarvoor toch een paar kleine aanpassingen nodig zijn om ze te laten werken voor een bepaalde afdeling of groep. Dit is geen probleem: u neemt de DTD gewoon op in de DOCTYPE-declaratie, waarna u de noodzakelijke programmeerdeclaraties aan de interne subset toevoegt.

U kunt een element dat al is gedefinieerd in de externe DTD niet opnieuw definiëren, maar dat kan wel voor entiteiten en standaardwaarden voor attributen.

Als u uw XML-documenten schrijft met een tekstverwerker kunt u de overeenkomstige DTD doorlezen en ervoor zorgen dat aan alle regels is voldaan. Maar u weet pas echt zeker dat u dat heeft gedaan na validatie van het XML-document t.o.v. de DTD met een programma dat we een "validating parser" noemen. De validating parser leest de DTD en controleert vervolgens uw XML-bestand om ervoor te zorgen dat het voldoet aan alle regels van de DTD. Een goede validating parser vertelt u ook welke (eventuele) problemen hij is tegengekomen.

Vergeet niet dat als u een XML-document wilt vergelijken met een specifieke DTD u een validating XML parser nodig heeft en niet een gewone XML parser. Er zijn weliswaar veel XML parsers die laten weten of een XML-bestand goed is gestructureerd, maar er zijn er maar weinig die voor u uitzoeken of een XML-bestand geldig is.

Zie Bijlage B "Snel wegwijs in DTD's" in hoofdstuk 7 "Bijlagen" als u even vlug wilt kennismaken met de DTD-functies en -regels.

Moet u nu zelf een nieuwe DTD gaan ontwerpen, die helemaal is geënt op uw bedrijf? Of moet u gebruik maken van een gestandaardiseerde DTD die u ontwikkeltijd zal besparen en u de garantie zal geven dat u informatie kunt uitwisselen met andere organisaties in uw bedrijfstak?

Er valt voor beide benaderingen iets te zeggen. Als u van de grond af aan uw eigen DTD maakt, heeft u de structuur van die DTD en het updaten daarvan volledig in eigen hand. U wordt echter ook geconfronteerd met een aanzienlijke investering in tijd en werk, terwijl u goed moet overwegen wie met deze DTD gaan werken en wat daarbij de wensen zijn. Wanneer u gebruik maakt van een gestandaardiseerde DTD kunt u dat proces van het ontwikkelen van een eigen DTD overslaan, maar u zult zich hoe dan ook moeten houden aan de DTD-regels en de structuur die daarin wordt gedefinieerd.

Als u van plan bent informatie uit te wisselen met andere bedrijven, kan een gestandaardiseerde DTD een goed idee zijn. Een gestandaardiseerde DTD kan een garantie zijn voor het probleemloos uitwisselen van gegevens, terwijl de informatie die u codeert opnieuw in een andere context kan worden gebruikt. Dit is ook een van de redenen geweest dat men overging tot de ontwikkeling van XML: Als hulpmidddel bij de standaardisatie van de structuren waarin informatie wordt opgeslagen en uitgewisseld.

Maar een gestandaardiseerde DTD heeft ook zijn eigen uitdagingen, omdat twee bedrijven andere wensen kunnen hebben, zelfs als de gegevens waarmee ze werken in essentie identiek zijn. Gestandaardiseerde DTD's kunnen per bedrijf worden aangepast, maar dat tast gedeeltelijk de doelstelling aan waarvoor een DTD wordt gecreëerd, namelijk een garantie dat informatie tussen bedrijven onderling wordt opgeslagen in een consequent doorgevoerde structuur.

Of u wel of niet wat heeft aan een gestandaardiseerde DTD hangt af van een paar factoren.

Is er voor uw bedrijfstak wel een gestandaardiseerde DTD beschikbaar?

Om achter het antwoord op deze vraag te komen, kunt u eens gaan kijken op het World Wide Web. Twee goede locaties om te zoeken zijn www.schema.net en www.xml.org.

En als er een gestandaardiseerde DTD is, voldoet deze dan aan uw wensen?

• Als u een gestandaardiseerde DTD kunt vinden die ogenschijnlijk goed werkt voor uw bedrijf, bekijk hem dan eerst heel goed voordat u hem gaat gebruiken. Een niet correcte DTD kan leiden tot ernstige problemen. Een dergelijke DTD kan:
• auteurs dwingen te werken met onbekende en onjuiste structuren;
• auteurs als het ware gegevens laten persen in verkeerde elementen;
• een beperking opleveren voor het indexeren van en zoeken naar informatie;
• leiden tot te veel speelruimte, waardoor er ongeldige codes kunnen insluipen;
• de conversie naar andere structuren bemoeilijken;
• leiden tot de aanschaf van te ingewikkelde programma's voor het verwerken van de gegevens;
• leiden tot enorme kosten als uiteindelijk de DTD onbruikbaar blijkt te zijn, zodat u genoodzaakt bent al uw gegevens in een andere structuur om te zetten.

Denk hierover dus heel goed na. Als de DTD van uw keuze niet aan uw wensen voldoet, zal het cumulatieve effect van de tekortkomingen waarschijnlijk steeds meer merkbaar worden.

Als er voor uw bedrijfstak geen gestandaardiseerde DTD is, is er dan één in ontwikkeling?

Indien u geen gestandaardiseerde DTD kunt vinden die voldoet aan de wensen binnen uw bedrijf, kunt u eens proberen uit te zoeken of iemand in uw bedrijfstak misschien bezig is er één te ontwikkelen. Als dat het geval is, kan uw bedrijf misschien zijn steentje bijdragen aan de ontwikkeling van de definitieve DTD. Door deel te nemen aan de ontwikkeling van een gestandaardiseerde DTD kunt u voorkomen dat de problemen ontstaan die altijd opduiken als een DTD wordt overgenomen van iemand die geen idee heeft van wat er bij u speelt.

Sommige bedrijven kiezen voor het gebruik van een gestandaardiseerde DTD, maar bewerken dan die DTD zodanig dat deze aan hun specifieke eisen voldoet. Om bijvoorbeeld met de ISO-standaard SGML DTD "book" te kunnen werken, maakte de University of California Press een serie aanpassingen, waarbij elementen werden toegevoegd die het mogelijk maakten informatie als subtitels en auteursvermeldingen in specifieke hoofdstukken op te slaan. De ISO (International Standards Organization) geeft richtlijnen voor het wijzigen van zijn DTD's, dus zelfs als u dergelijke aanpassingen maakt, is uw nieuwe DTD toch nog enigszins gestandaardiseerd.

Wat gebeurt er als u gegevens wilt uitwisselen met andere bedrijven die wel gebruik maken van de oorspronkelijke, ongewijzigde DTD? Sommige bedrijven maken dan hulpprogramma's waarmee documenten met gewijzigde DTD's kunnen worden geconverteerd naar documenten die de richtlijnen volgen van de oorspronkelijke vorm van de DTD. Een dergelijke oplossing geeft u veel van de voordelen van een aan uw smaak aangepaste DTD, terwijl u toch nog gegevens kunt uitwisselen met andere organisaties in dezelfde bedrijfstak.

Met avenue.quark kunt u een DTD gebruiken om gestructureerde content uit QuarkXPress Passport-documenten te halen en die content op te slaan in het bestandssysteem of in een database. In de volgende alinea's wordt dit proces beschreven aan de hand van een praktijkvoorbeeld.

Stel dat uw bedrijf een groot aantal technische documenten in QuarkXPress Passport-structuur heeft gemaakt en u wilt hun content exporteren in XML-structuur en deze vervolgens opslaan in een database, zodat uw klanten op het Web erover kunnen beschikken. De technische documenten gebruiken alle hetzelfde QuarkXPress Passport-sjabloon en dezelfde typogrammen.

Voordat u de content uit de technische documenten kunt halen en in een bepaalde structuur zetten, moet u kunnen beschikken over een structuur om de content in te zetten. De DTD geeft u die structuur.

Wilt u meer weten over DTD's kijk dan bij "Werken met DTD's" in dit hoofdstuk.

Er zijn twee manieren om aan een DTD te komen die u in avenue.quark kunt gebruiken:

• Kies een bestaande XML DTD. Er zijn op dit moment al verscheidene gestandaardiseerde XML DTD's beschikbaar en naarmate XML steeds meer wordt toegepast, komen er natuurlijk ook steeds meer van dergelijke DTD's. Als u voor deze manier kiest, moet u wel goed uw gedachten laten gaan over de DTD die u wilt gebruiken; een DTD die niet voldoet, kan het leven van degenen die ermee moeten werken aardig zuur maken.
• Ontwikkel uw eigen DTD. Lees eerst de alinea "Werken met DTD's" in dit hoofdstuk, analyseer vervolgens heel zorgvuldig de onderdelen waaruit de technische documentatie is samengesteld en ontwikkel een DTD die daarmee overeenkomt. Dit proces kan tijdrovend zijn, maar dat is best de moeite waard als het resultaat een DTD is waarmee u uit de voeten kunt. Over het algemeen zijn het de medewerkers van een redactie of administratie die een DTD selecteren.

Maak een nieuw XML-document in avenue.quark en specificeer daar de DTD die u heeft gekozen in stap 1. De verplichte elementen in de DTD worden automatisch in het XML-document ingevoegd.

Het XML Werkblad-palet voor een nieuw XML-document

Een van de unieke functies van avenue.quark is op regels gebaseerde codering. U maakt daarbij een set met codeerregels die avenue.quark bijvoorbeeld vertellen dat een alinea waaraan het typogram "Kopregel" is toegekend, moet worden gecodeerd als een <Titel>. U kunt sets met codeerregels ook gebruiken om aan te geven hoe bepaalde typogrammen, tekstkleuren en lokale vormgeving moeten worden gecodeerd. (Raadpleeg voor meer informatie over sets met codeerregels hoofdstuk 5 "Codeerregelsets".)

Bewaar het XML-document als een sjabloon met de naam "TechDoc.xmt." Het sjabloon bevat de DTD van het technische document en de set met codeerregels die u in stap 3 heeft gemaakt. U kunt dit sjabloon gebruiken om zoveel XML-bestanden te maken als u wilt. Dit kan op één en dezelfde computer, of verdeeld over meerdere computers.

Wanneer u in avenue.quark een nieuw XML-document maakt, is het eerste wat u moet doen in de Sjabloon-lijst een sjabloon kiezen waarop het nieuwe XML-document moet worden gebaseerd. In dit voorbeeld kiezen we het sjabloon "TechDoc.xmt" uit stap 4.

Met het TechDoc.xmt-sjabloon kunt u op eenvoudige wijze een technisch document in QuarkXPress Passport van codes voorzien.

Om de op de set met codeerregels gebaseerde codes aan te brengen, Command+sleept (Mac OS) of Ctrl+sleept (Windows) u het kader met de tekst van het technische document op het <techDoc>-element in de XML Tree-schuiflijst. Avenue.quark codeert het document automatisch overeenkomstig de regels in de codeerregelset.

Wilt u gebruik maken van op regels gebaseerde codering, Command+sleep (Mac OS) of Ctrl+sleep (Windows) het kader dan gewoon op het juiste element in de XML Tree-lijst. Avenue.quark gebruikt de codeerregelset om zoveel mogelijk van de content te coderen.

Aan sommige technische documenten hoeft na het toekennen van de codes met behulp van de codeerregelset niets meer te worden gedaan. Maar andere documenten hebben vast nog wel wat content die handmatig zal moeten worden gecodeerd, of er zijn nog gevallen waarin content meer dan één code zou kunnen hebben. Om dergelijke situaties op te lossen, sleept u gewoon de content in kwestie op het juiste element in het XML Werkblad-palet.

Staat de content van uw technische document eenmaal in XML-structuur, dan kunt u deze met behulp van een groot assortiment gereedschappen op het Web zetten. U kunt het document publiceren als een gewoon XML-bestand en het bekijken met een nieuwere Web browser zoals Microsoft Internet Explorer 5.0. XML-gecodeerde content kan ook worden gebruikt op veel andere manieren, variërend van elektronische gegevensuitwisseling tot het uitdraaien van geprinte documenten.